JVM运行原理详解

专注于编程、互联网动态。最终将总结的技术、心得、经验（数据结构与算法、源码分析等）享给大家，这里不只限于技术！还有职场心得、生活感悟、以及面经。点击上方 "程序员小乐" ，关注公众号，第一时间送达！

每日英文 

Don’t give up.I believe in you all. A person’s a person no matter how small. 

不要放弃。我坚信你能行。人就是人，无论多么卑微。

乐乐有话说 

人往往在闲得发慌的时候最矫情最脆弱，在深渊挣扎的时候最清醒最坚强 。

来自：habit_learning

链接：https://www.jianshu.com/p/9b0b7409f292

封面来自网络

01 JVM 简析  

作为一名Java 使用者，掌握 JVM 的体系结构是很有必要的。

说起Java ，我们首先想到的是Java 编程语言，然而事实上，Java 是一种技术，它由四方面组成：Java 编程语言、Java 类文件格式、Java 虚拟机 和 Java 应用程序接口（Java API）。他们的关系图如下：

Java平台

Java 平台由 Java 虚拟机和 Java 应用程序接口搭建，Java 语言则是进入这个平台的通道，用Java 语言编写并编译程序可以运行在这个平台上。这个平台的结构如下所示：运行期环境代表着Java平台，开发人员编写Java 代码（.java文件），然后将之编译成字节码（.class文件），再然后字节码被装入内存，一旦字节码进入虚拟机，它就会被解释器解释执行，或者被即时代码发生器有选择的转换成机器码执行。

Java平台无关性

JVM 在它的生命周期中有一个明确的任务，那就是运行Java 程序，因此当Java 程序启动的时候，就产生JVM 的一个实例；当程序运行结束的时候，该实例也跟着消失了。在Java 平台的结构中，可以看出，JVM 在核心的位置，是程序与底层操作系统和硬件无关的关键。它的下方是移植接口，移植接口由两部分组成：适配器和Java 操作系统，其中依赖平台的部分称之为适配器；JVM 通过移植接口在具体的平台和操作系统上实现；JVM 的上方是Java 基本类库和扩展类库以及他们的API,利用Java API 编写的应用程序（application）和小程序（Java applet）可以再任何Java 平台上运行而无需考虑底层平台，就是因为有Java 虚拟机（JVM）实现了程序与操作系统的分离，从而实现了Java 的平台无关性。

下面，我们从JVM 的基本概念和运行过程这两个方面入手，来对它进行深入的研究。

02 JVM 基本概念  

（1）基本概念：

JVM 是可运行Java 程序的假想计算机，包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收、堆和一个存储方法域。JVM 是运行在操作系统之上的，它与硬件没有直接的交互。

（2）运行过程

我们都知道Java 源文件，通过编译器，能够产生相应的.class文件，也就是字节码文件，而字节码文件又通过Java 虚拟机的解释器，解释成特定机器上的机器码。

也就是如下：

① Java 源文件 ——> 编译器 ——> 字节码文件

② 字节码文件 ——> JVM ——> 机器码

每一种平台的解释器是不同的，但是实现的虚拟机是相同的，这也就是Java 为什么能跨平台的原因了，当一个程序开始运行，这时虚拟机就开始实例化了，多个程序启动就会存在多个虚拟机实例。程序退出或者关闭，则虚拟机实例消亡，多个虚拟机实例之间数据不能共享。     

03 JVM 的体系结构  

JVM 的体系结构

（1）Class Loader 类加载器

负责加载.class文件，class文件在文件开头有特定的文件标识，并且ClassLoader 负责class文件的加载。

类的生命周期：加载 ——> 验证 ——> 准备 ——> 解析 ——> 初始化 ——> 使用 ——> 卸载

1、加载：

① 通过一个类的全限定名，来获取此类的二进制字节码；

② 将这个字节码所代表的静态存储结构转化为方法区的运行时数据结构；

③ 在Java堆中生成一个代表这个类的Class对象，作为方法区这些数据的访问路口。

2、验证：文件格式验证、元数据验证、字节码验证等。

3、准备：准备阶段是正式为静态变量分配内存并设置静态变量初始值（各数据类型的零值）的阶段，这些内存将在方法区中进行分配。但是如果静态变量的字段属性为常量，则会初始化为指定的值，而不是零值。

4、解析：解析阶段是在虚拟机将符号引用替换为直接引用的过程。直接引用可以是直接指向目标的指针、相对偏移量。

5、初始化：为类的静态变量赋予指定的初始值。

6、使用：使用类之前，必须对类进行实例化，如new或者反射。只有实例化了，才能通过对象的引用来访问对象的实例。

7、卸载：执行垃圾回收。

双亲委派机制：

JVM的类加载是通过ClassLoader及其子类来完成的，类的层次关系和加载顺序可以由下图来描述：

ClassLoader 类加载机制

自上而下尝试加载，最下面的加载器没有加载到的话，则抛出ClassNotFoundException。

Bootstrap ClassLoader启动类加载器：加载\lib路径下的jar包，即JDK核心jar包；

Extension ClassLoader扩展类加载器：加载\lib\ext路径下的jar包；

App ClassLoader应用程序类加载器：加载用户类路径 java -classpath 上所指定的类库。

双亲委派机制的优势：

系统安全性：Java类随着加载它的类加载器一起具备了一种带有优先级的层次关系。比如，Java中的Object类，它存放在rt.jar之中,无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object在各种类加载环境中都是同一个类。如果不采用双亲委派模型，那么由各个类加载器自己去加载的话，那么系统中会存在多种不同的Object类。

（2） Native Interface 本地接口

本地接口的作用是融合的不同编程语言为Java 所用，它的初衷是融合C/C++ 程序，Java 诞生的时候C/C++ 横行的时候，要想立足，必须调用C/C++ 程序，于是就在内存中专门开辟了一块处理标记为native 的代码，它的具体做法是Native Method Stack 中登记native 方法，在Execution Engine 执行加载native libraries。

（3）Execution Engine 执行引擎

执行包在类装载的方法中的指令。

（4）Runtime data area 运行数据区

虚拟机内存，从整个计算机内存中开辟一块内存存储JVM 需要用到的对象、变量等，运行区数据又分为很多小区：方法区，虚拟机栈，本地方法栈，堆，程序计数器。

4 JVM 数据运行区详解（栈管理运行，堆管理存储）

JVM 运行时数据区

说明：JVM 调优主要就是优化 Heap堆 和 Method Area 方法区，并且这两个区域是线程共享的数据区。

（1）Native Method Stack 本地方法栈

Native Method Stack 登记native 方法，在Execution Engine 执行加载native libraries。

（2）PC Register 程序计数器

每个线程都有一个程序计数器，就是一个指针，指向方法区中的方法字节码（下一个将要执行的指令代码），由执行引擎读取下一条指令。

（3）Method Area 方法区

方法区是被所有线程共享，所有字段和字节码，以及一些特殊方法如构造器，接口代码也在此定义。简单说，所有定义的方法的信息都保存在该区域，此区域属于共享区间。

静态变量 + 常量 + 类信息 + 运行时常量池存在方法区中，实例对象存在堆内存中。

（4）Stack 栈

① 栈是什么

栈也叫栈内存，主管Java 程序的运行，是在线程创建时创建，它的生命周期跟随线程的生命周期，线程结束栈内存也就释放，对于栈来说，不存在垃圾回收问题，只要线程一结束栈就Over，生命周期和线程一致，是线程私有的。

基本类型的变量和对象的引用变量都是在栈内存中分配的，但是对象的实例还是保存在堆中的。

② 栈存储什么？

栈帧中主要保存3类数据：

局部变量（Local Variables）：输入参数和输出参数以及方法类的变量；

栈操作（Operand Stack）：记录出栈、入栈的操作；

栈帧数据（Frame Data）：包括类文件、方法等等。

③ 栈运行原理

栈中的数据都是以栈帧（Stack Frame）的格式存在的，栈帧是一个内存区块。当一个方法被A 调用时就产生了一个栈帧F1，并被压入到栈中，A 方法又调用了B方法，于是产生栈帧F2 也被压入栈，B方法又调用了C 方法，于是产生栈帧F3 也被压入栈，依次执行完毕后，先弹出F3 栈帧，再弹出F2 栈帧，再弹出F1 栈帧。遵循“先进后出”原则。

当出现递归方法，参数个数过多、递归过深、递归没有出口时，就有可能报StackOverflow异常。

（5）Heap 堆

堆这块区域是JVM 中最大的，实例对象（成员变量，方法）都是存在这个区域，这块区域是GC 主要的回收区，一个 JVM 实例只存在一个堆内存，堆内存大小是可以调节的。类加载器读取了类文件后，需要把类、方法放到堆内存中，以方便执行器执行，堆内存分为三部分：

Heap 堆内存

① 新生代

新生代是类的诞生、成长、消亡的区域，一个类在这里产生、应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分：伊甸区（Eden space）和幸存区（Survivor pace），绝大多数的类都是在伊甸区被 new 出来的。幸存区有两个：0区（Survivor 0 space）和 1区（Survivor 1 space）。两个Survivor 区空间一样大，当Eden 区满了，则会触发普通GC，若 Eden 区中的对象经过垃圾回收没有被回收掉，会将Eden 区中的幸存对象移动到幸存0区。若幸存0区也满了，再对该区域进行垃圾回收，然后移动到1区，然后之前的0区将置为空，没有任何数据。显然，Survivor 区只是增加了对象在年轻代中逗留的时间，增加了被垃圾回收的可能性。那如果1区也满了呢？再移动到养老区。若养老区也满了，那么这时候将产生Full GC，进行养老区的内存清理。若养老区执行Full GC 之后发现依然无法进行对象的保存，就会产生 OOM 异常“OutOfMemoryError”。

新生代特点：每次垃圾回收时都有大量的对象需要被回收。垃圾回收器在新生代采用的收集算法是Copying(复制)方法：它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块面对内存用完了，就将还存活的对象复制到另外一块，然后再把已使用的内存空间一次清理掉。由于新生代有每次垃圾回收时都有大量的对象需要被回收的特点，所以采用Copying算法，复制的存活对象较少，性能比较好。但是Copying算法还是有缺陷的，那就是内存的使用率只有一半。

Copying

如果出现 java.lang.OutOfMemoryError: Java heap space 异常，说明Java 虚拟机的堆内存不够。可能产生的原因如下：

1、Java 虚拟机的堆内存设置不够，可以通过-Xms、-Xmx来调整；
2、代码中创建了大量大对象，并且长时间不能被垃圾回收器收集；
3、内存加载的数据量太大：一次性从数据库取太多数据；
4、集合类中有对对象的引用，使用后未清空，GC不能进行回收；
5、代码中存在循环产生过多的重复对象。

② 老年区

年轻代中经过垃圾回收没有回收掉的对象将被Copy到年老代。

老年代的特点： 每次垃圾回收时只有少量的对象需要被回收。垃圾回收器在老年代采用的收集算法是 Mark-Compac t算法：为了解决Copying算法的缺陷，充分利用内存空间，提出了Mark-Compact算法。它先将需要回收的对象进行标记，然后将存活对象都向一端移动，然后清理掉端边界以外的内存。

Mark-Compact

③ 永久区

永久代存放类的常量、静态变量等信息，是方法区的实现。对永久代的回收主要回收两部分内容：废弃常量和无用的类。

如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java 虚拟机对永久带Perm内存设置不够。原因有二：

1、程序启动需要加载大量的第三方jar包。例如：在一个Tomcat 下部署了太多的应用。
2、大量动态反射生成的类不断被加载，最终导致Perm 区被占满。

注意：JDK1.8 之后，不存在永久带，即没有java.lang.OutOfMemoryError: PermGen space 这种错误。取而代之的是Meta space（元空间）。之前存储在永久带的字符串常量，静态变量移到了堆中去了，元空间不存储在堆中，而是存储在本地内存中。

JDK 1.8之前堆内存结构图

JDK 1.8堆内存结构图

说明：方法区和堆内存的异议：

实际而言，方法区和堆一样，是各个线程共享的内存区域，它用于存储虚拟机加载的：类信息 + 常量 + 静态变量 + 编译器编译后的代码等等。
常量池（Constant Pool）是方法区的一部分，Class 文件除了有类的版本、字段、方法、接口等描述信息外，还有一项就是常量池，这部分内容将在类加载后进入方法区的运行时常量池中存放。

04 垃圾回收机制  

垃圾回收：当一个对象没有引用指向它时，这个对象就成为无用的内存（垃圾），就必须进行回收，以便于后续其他对象的内存分配。

判断对象是否存活的方法——可达性分析：程序把所有的引用关系看做一张图，如果一个节点与GC Roots之间没有引用链存在，则该节点视为垃圾回收的对象。

可作为GC Roots对象的包括如下几种：

1、虚拟机栈（栈帧中的本地变量表）中引用的对象；
2、方法区中的静态变量引用的对象；
3、方法区中常量引用的对象；
4、本地方法栈中JNI(Java Native Interface)引用的对象。

05 内存调优简介  

内存调优参数

JDK 1.8内存容量查询

说明：在Run Config中的 vm options 中输入“-XX:+PrintGCDtails”，可以看到堆内存运行情况：

JDK1.8 内存运行情况（示例）

（1） 堆大小设置

典型设置：

1、java -Xmx3550m -Xms3550m -Xmn2g -Xss128k

-Xmx3550m：设置JVM 最大可用内存为3550M。

-Xms3550m：设置JVM 初始内存为3550m。此值可以设置与-Xmx 相同，以避免每次垃圾回收完成后JVM 重新分配内存。

-Xmn2g：设置新生代大小为2G。整个JVM内存大小 = 新生代大小 + 老年代大小  + 元空间。Sun 官方推荐配置为整个堆内存的3/8。

-Xss256K：每个线程默认会开启1M的堆栈，用于存放栈帧、调用参数、局部变量等，对大多数应用而言这个默认值太了，一般256K就足用。理论上，在内存不变的情况下，减少每个线程的堆栈，可以产生更多的线程，但这实际上还受限于操作系统。

2、java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4  -XX:MaxTenuringThreshold=3

-XX:NewRatio = 4：设置新生代（包括Eden和两个Survivor 区）与老年代（出去元空间）的比值。设置为4，则新生代与老年代所占比值为1:4，新生代占整个堆内存的1/5。

-XX:SurvivorRatio = 4：设置新生代Eden 区与Survivor 区的大小比值。设置为4，则两个Survivor 区与一个Eden 区的比例为2:4，一个Survivor 区占整个年轻代的1/6。

-XX:MaxTenuringThreshold=3：设置垃圾最大年龄为3，即对象在Survivor 区存在的年龄为3（复制一次年龄+1）。如果设置为0，则年轻代对象不经过Survivor 区，直接进入老年代。对于老年代比较多的应用，可以提高效率。如果将此设置为一个较大的值，则年轻代对象会在Survivor 区进行多次复制，这样可以增加对象在年轻代存活的时间，增加在年轻代被回收的概率。此参数只有在串行GC时才有效。

（2）回收器选择

JVM 给了三种选择：串行收集器（单线程）、并行收集器、并发收集器，但是串行收集器只适用于小数据量的情况。默认情况下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应的参数。JDK5.0以后，JVM会根据当前系统配置进行判断。

并行算法是用多线程进行垃圾回收，回收期间会暂停程序的执行，而并发算法，也是多线程回收，但期间不停止应用执行。所以，并发算法适用于交互性高的一些程序。经过观察，并发算法会减少年轻代的大小，其实就是使用了一个大的年老代，这反过来跟并行算法相比吞吐量相对较低。

垃圾回收动作何时执行？

1）当年轻代内存满时，会引发依次普通的GC，该GC仅回收年轻代。需要强调的是，年轻代满是指Eden 区满，Survivor 区满并不会引发GC。
2）当老年代满时会引发Full GC，Full GC将会同时回收年轻代、老年代。
3）当永久带满时也会引发Full GC，会导致Class、Method元信息的卸载（JDK8 没有永久带，替代的是元空间）。

JVM 中如何判断对象是否存活？

1）引用计数算法：

给对象中添加一个引用计数器，每当一个地方引用它时，计数器加1；当引用失效时（如出方法），计数器减1。计数器值为0时，对象就是不可能被使用了。

JVM（hotspot） 并没有采用上面这种方法来判断对象的存活，原因是它很难解决对象之间相互引用的问题。在下面的代码中，我们在testGC()中new两个ReferenceCountingGC对象objA和objB，然后令objA.instance=objB，objB.instance=objA，最后令objA和objB都为null。此时，这两个对象实际上已经不可能再被访问，但由于它们互相引用着对方，导致它们的引用计数器值都不为0，于是使用引用计数算法无法通知GC收集器回收它们。

2）可达性分析算法：

JVM（hotspot）判断对象的存活，采用的是此方法。通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下探索，探索所走过的路径称为“引用链”，当一个对象到 GC Roots 没有任何引用链相连（从GC Roots 到这个对象不可达）时，则证明此对象是不可用的。如下图中，对象object5、object6、object7虽然互有关联，但是它们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象。

在 Java 语言中，可作为 GC Roots 的对象包括下面几种：

1、虚拟机栈（栈帧中的本地变量表，如方法入参）中的引用对象；
2、方法区中类静态属性引用的对象；
3、方法区中常量引用的对象；
4、本地方法栈中JNI（native 方法）引用的对象。

1、吞吐量优先的并行收集器

并行收集器主要以达到一定吞吐量为目标，适用于后台处理等。

典型配置：

        java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -
        XX:+UseParallelGC -XX:ParallelGCThreads=20 

-XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。

-XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。

        java -Xmx3550m -Xms3550m -Xmn2g -Xss128k 
        -XX:+UseParallelGC -XX:ParallelGCThreads=20 
        -XX:+UseParallelOldGC

-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。

        java -Xmx3550m -Xms3550m -Xmn2g -Xss128k 
        -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100

-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。

        java -Xmx3550m -Xms3550m -Xmn2g -Xss128k 
        -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100 
        -XX:+UseAdaptiveSizePolicy

-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。

2、响应时间优先的并发收集器

并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。

典型配置：

        java -Xmx3550m -Xms3550m -Xmn2g -Xss128k  
        -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC  
        -XX:+UseParNewGC

-XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。

-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。

        java -Xmx3550m -Xms3550m -Xmn2g -Xss128k 
        -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 
        -XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。

-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片。

（3）调优总结

1、年轻代大小选择

响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。

2、年老代大小选择

① 响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：

1、并发垃圾收集信息
2、持久代并发收集次数
3、传统GC信息
4、花在年轻代和年老代回收上的时间比例

减少年轻代和年老代花费的时间，一般会提高应用的效率

② 吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。

3、较小堆引起的碎片问题

因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：

1、-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
2、-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩。

4、调优策略

调优的目标：

1、GC的时间足够小；
2、GC的次数足够小；
3、发送Full GC的周期足够长。

前两个目前是相悖的，要想GC 时间小必须要一个更小的堆；要保证GC 次数足够小，必须保证一个更大的堆，我们只能取其平衡。

（1）针对JVM堆的设置一般，可以通过-Xms，-Xmx限定其最小、最大值，为了防止垃圾收集器在最小、最大之间收缩堆而产生额外的时间，我们通常把最大、最小设置为相同的值。

（2）年轻代和年老代将根据默认的比例（1：2）分配堆内存，可以通过调整二者之间的比率NewRadio来调整二者之间的大小，也可以针对回收代，比如年轻代，通过 -XX:newSize（设置年轻代大小），-XX:MaxNewSize（设置年轻代最大值）来设置其绝对大小。同样，为了防止年轻代的堆收缩，我们通常会把-XX:newSize -XX:MaxNewSize设置为同样大小。

（3）年轻代和年老代设置多大才算合理？这个我问题毫无疑问是没有答案的，否则也就不会有调优。我们观察一下二者大小变化有哪些影响。

1、更大的年轻代必然导致更小的年老代，大的年轻代会延长普通GC的周期，但会增加每次GC的时间；小的年老代会导致更频繁的Full GC。

2、更小的年轻代必然导致更大年老代，小的年轻代会导致普通GC很频繁，但每次GC 的时间会更短；大的年老代会减少Full GC的频率。

（4）在配置较好的机器上（比如多核、大内存），可以为年老代选择并行收集算法：-XX:+UseParallelOldGC，默认Serial收集。

（5）可以通过下面的参数打印 Heap Dump 信息：

        -XX:HeapDumpPath

        -XX:+PrintGCDetails

        -XX:+PrintGCTimeStamps

        -Xloggc:/usr/aaa/dump/heap_trace.txt

通过下面参数可以控制OutOfMemoryError时打印堆的信息：

        -XX:+HeapDumpOnOutOfMemoryError

提供一个的Java参数配置示例：（服务器：Linux 64Bit，8Core×16G）

        JAVA_OPTS="$JAVA_OPTS -server -Xms3G -Xmx3G -Xss256k 
        -XX:PermSize=128m -XX:MaxPermSize=128m 
        -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError 
        -XX:HeapDumpPath=/usr/aaa/dump -XX:+PrintGCDetails 
        -XX:+PrintGCTimeStamps 
        -Xloggc:/usr/aaa/dump/heap_trace.txt 
        -XX:NewSize=1G -XX:MaxNewSize=1G"

如果您觉得不错，请别忘了转发、分享、点赞让更多的人去学习， 您的举手之劳，就是对小乐最好的支持，非常感谢！

如何您想进技术群交流，关注公众号在后台回复 “加群”，或者 “学习” 即可

著作权归作者所有，欢迎大家投稿

推荐阅读

看完本文有收获？请转发分享给更多人
关注「程序员小乐」，提升技能